Skip to content

fix: evaluate window aggregate arguments after FILTER - #24508

Open
lyne7-sc wants to merge 6 commits into
apache:mainfrom
lyne7-sc:fix/window-filter-argument-evaluation
Open

fix: evaluate window aggregate arguments after FILTER#24508
lyne7-sc wants to merge 6 commits into
apache:mainfrom
lyne7-sc:fix/window-filter-argument-evaluation

Conversation

@lyne7-sc

@lyne7-sc lyne7-sc commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Which issue does this PR close?

Rationale for this change

Window aggregates evaluate their arguments before applying FILTER, which can cause errors on rows that should not participate in the aggregate.

This is analogous to #24444 for grouped aggregates, window aggregates use a separate evaluation path.

What changes are included in this PR?

Evaluate the window aggregate filter before evaluating its arguments.

Use the resulting filter mask as a selection when evaluating argument expressions. Selected results are scattered back to the original batch length so that window frame row indices remain aligned.

This applies to both ever-expanding and sliding aggregate window frames.

Are these changes tested?

Yes.

Are there any user-facing changes?

Window aggregate arguments are no longer evaluated for rows rejected by FILTER, no public API changes.

@github-actions github-actions Bot added physical-expr Changes to the physical-expr crates sqllogictest SQL Logic Tests (.slt) labels Aug 20, 2026
@codecov-commenter

codecov-commenter commented Aug 20, 2026 •
edited
Loading

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 83.96226% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.44%. Comparing base (3ace5a0) to head (998af0a).
⚠️ Report is 3 commits behind head on main.

Files with missing lines Patch % Lines
datafusion/physical-expr/src/window/window_expr.rs 83.96% 4 Missing and 13 partials ⚠️
Additional details and impacted files 
@@            Coverage Diff             @@
##             main   #24508      +/-   ##
==========================================
- Coverage   81.44%   81.44%   -0.01%     
==========================================
  Files        1118     1118              
  Lines      399560   399634      +74     
  Branches   399560   399634      +74     
==========================================
+ Hits       325424   325483      +59     
- Misses      55137    55143       +6     
- Partials    18999    19008       +9

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

neilconway
neilconway reviewed Aug 20, 2026
View reviewed changes

@neilconway neilconway left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This approach makes sense and is simple and clean, but I'd be curious to understand how it influences performance, especially for simple and infallible expressions (e.g., bare column references).

@lyne7-sc

lyne7-sc commented Aug 21, 2026

Copy link
Copy Markdown
Contributor Author

Thanks for the review! I think this could cause a performance regression when the window argument is a direct column or another cheap expression. In these cases, the cost of filtering the entire batch and scattering the result back to the original row positions may exceed the expression evaluation cost that we skip.

As a low-risk mitigation, we could bypass evaluate_selection for expressions that are known to be safe and cheap to evaluate on the original batch, as follows:

let value = if can_evaluate_window_arg_unfiltered(expr) {
    // These expressions cannot fail because of values in excluded rows.
    expr.evaluate(batch)?
} else {
    // Fallible expressions must only see selected rows.
    expr.evaluate_selection(batch, selection)?
};

This could address the most obvious regressions for direct columns and literals. However, it would only be a temporary mitigation and would not cover other cheap expressions such as column + 1.

One possible long-term direction might be to keep the selected argument values in compact form instead of scattering them back. We could maintain a prefix-count array that maps each boundary in the original row space to the corresponding boundary in the compact argument arrays:

selection:      T F T F
prefix:         0 1 1 2 2

original frame: [start, end)
compact frame:  [prefix[start], prefix[end])

Window frame calculation and output rows could remain in the original row space, while only the ranges passed to the accumulator would be mapped into the compact arrays. This could allow us to skip evaluating expressions for excluded rows while still producing the correct window results. It could also avoid per-argument scatter and the additional filtering before update_batch/retract_batch.

I'm not sure whether this approach would improve performance in practice. does this direction make sense to you?

@neilconway

neilconway commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

@lyne7-sc Yep, that all makes sense -- both the short-term mitigation and the longer-term optimization possibility. Should we start by adding a micro-benchmark to cover the window agg + FILTER case and then proceed from there?

@lyne7-sc lyne7-sc mentioned this pull request Aug 23, 2026
Open
@lyne7-sc

lyne7-sc commented Aug 23, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

@neilconway yes, that makes sense. I've added the microbenchmark separately in #24589.

Here are the results from my local:

group                                                                   fix                                    main
-----                                                                   ---                                    -------
window_aggregate_filter/bounded_cumulative/column/10_percent            1.01      9.9±0.38ms        ? ?/sec    1.00      9.8±0.33ms        ? ?/sec
window_aggregate_filter/bounded_cumulative/column/30_percent            1.00      9.2±0.23ms        ? ?/sec    1.03      9.5±0.24ms        ? ?/sec
window_aggregate_filter/bounded_cumulative/column/50_percent            1.00      8.5±0.21ms        ? ?/sec    1.01      8.5±0.28ms        ? ?/sec
window_aggregate_filter/bounded_cumulative/divide/10_percent            1.11     11.7±0.37ms        ? ?/sec    1.00     10.5±0.54ms        ? ?/sec
window_aggregate_filter/bounded_cumulative/divide/30_percent            1.13     10.9±0.27ms        ? ?/sec    1.00      9.7±0.28ms        ? ?/sec
window_aggregate_filter/bounded_cumulative/divide/50_percent            1.14     10.5±0.27ms        ? ?/sec    1.00      9.2±0.33ms        ? ?/sec
window_aggregate_filter/bounded_cumulative/power_udf/10_percent         1.00     11.6±0.32ms        ? ?/sec    1.00     11.6±0.50ms        ? ?/sec
window_aggregate_filter/bounded_cumulative/power_udf/30_percent         1.03     11.2±0.25ms        ? ?/sec    1.00     10.8±0.45ms        ? ?/sec
window_aggregate_filter/bounded_cumulative/power_udf/50_percent         1.08     10.7±0.27ms        ? ?/sec    1.00      9.8±0.25ms        ? ?/sec
window_aggregate_filter/bounded_sliding_10_rows/column/30_percent       1.00     16.5±0.29ms        ? ?/sec    1.03     17.0±0.57ms        ? ?/sec
window_aggregate_filter/bounded_sliding_10_rows/power_udf/30_percent    1.13     20.8±0.49ms        ? ?/sec    1.00     18.4±0.46ms        ? ?/sec
window_aggregate_filter/window_whole_partition/column/30_percent        1.57     36.3±6.73µs        ? ?/sec    1.00     23.0±0.78µs        ? ?/sec
window_aggregate_filter/window_whole_partition/power_udf/30_percent     1.00   153.0±19.04µs        ? ?/sec    1.93    295.3±6.61µs        ? ?/sec

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@neilconway neilconway neilconway left review comments

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

physical-expr Changes to the physical-expr crates sqllogictest SQL Logic Tests (.slt)

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Window aggregate FILTER evaluates arguments for rejected rows

3 participants

@lyne7-sc @codecov-commenter @neilconway